Dynomotion

Group: DynoMotion Message: 5140 From: Kai Date: 6/4/2012
Subject: Hello, and a question
Hi all,

New to the group (KFlop is in the mail!), so hi everyone.

I'm using the MotionCNC/KFlop combo to support the CNC I'm building, and
have some architectural type questions:

How effective is the geometry correction table?

Trying to figure out how I'm going to build in alignment adjustments at
the physical level (making sure X Y Z are perpendicular, the two X axis
rails are levelled, etc). How far can I count on the software
correction to "do its thing"? Obviously if there are gross
misalignments the machine will seize, but will the S/W handle
corrections down to the resolution of the microsteps?

To be clear, its a 3 axis machine and the long (X) axis will have a
stepper on each side of the bed running in lockstep.

I'm assuming that the correction table is a once and forget - the
trajectory planner will automagically account for correction factors and
future G codes don't even have to think about it.

Thanks in advance for disabusing me of any delusions!

Cheers
Kai
Group: DynoMotion Message: 5141 From: Tom Kerekes Date: 6/4/2012
Subject: Re: Hello, and a question
Hi Kai,

What do you mean by "running in lockstep"?

Normally if you are using a slaved x axis you can adjust the xy orthogonality by performing a small move of one of the x motors after homing and before the two x motors are slaved together.

Regards
TK

Group: DynoMotion Message: 5146 From: kai432 Date: 6/5/2012
Subject: Re: Hello, and a question
Thanks Tom

I guess there are two things

1) Orthogonality - small offset could work - not entirely sure about deliberately putting the two X axis out of alignment though (increased dynamic errors and creepage over time)? Is it possible to have no brute force offset, but get the trajectory planner to re-project the vectors onto a corrected path? i.e. a line that was (0,0) to (0,Y) is now (0,0) to (Y sin theta,Y cos theta). Not sure if I got the maths right, I hope I painted the right picture...

Re: lockstep - I was thinking of slaved X's with independent homing but I'm happy enough with either implementation.

2) Non-linearity - If there are localised distortions, can the geometry table correct for those? E.g. one of the rails have a small bump, can the correction null out those errors? Or is it a matter of ensuring the physical rails are linear?

The general idea was understanding if the correction table puts the paths through some kind of a transformation.

Regards
Kai

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Kai,
>
> What do you mean by "running in lockstep"?
>
> Normally if you are using a slaved x axis you can adjust the xy orthogonality by performing a small move of one of the x motors after homing and before the two x motors are slaved together.
>
> Regards
> TK
>
>
>
> ________________________________
> From: Kai <kai@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, June 4, 2012 2:40 AM
> Subject: [DynoMotion] Hello, and a question
>
>
>
>  
> Hi all,
>
> New to the group (KFlop is in the mail!), so hi everyone.
>
> I'm using the MotionCNC/KFlop combo to support the CNC I'm building, and
> have some architectural type questions:
>
> How effective is the geometry correction table?
>
> Trying to figure out how I'm going to build in alignment adjustments at
> the physical level (making sure X Y Z are perpendicular, the two X axis
> rails are levelled, etc). How far can I count on the software
> correction to "do its thing"? Obviously if there are gross
> misalignments the machine will seize, but will the S/W handle
> corrections down to the resolution of the microsteps?
>
> To be clear, its a 3 axis machine and the long (X) axis will have a
> stepper on each side of the bed running in lockstep.
>
> I'm assuming that the correction table is a once and forget - the
> trajectory planner will automagically account for correction factors and
> future G codes don't even have to think about it.
>
> Thanks in advance for disabusing me of any delusions!
>
> Cheers
> Kai
>
Group: DynoMotion Message: 5147 From: Tom Kerekes Date: 6/5/2012
Subject: Re: Hello, and a question
Hi Kai,
 
Yes skewing slightly (or straightening) the axis is the way most handle Orthogonality.  Ideally the relaxed position should be nearly orthogonal.  It would be a good idea to have a switch detect excessive skew and kill power if skew ever becomes large in case of a motor failure or a mis-typed command which might cause only one motor to move.  Not sure how easy it would be to rig a switch to detect a small amount of skew, but I think it would be prudent if you can manage it.
 
Yes the Geo Correction table should be able to do either #1 or #2 of what you describe.  It only applies to our Trajectory Planner/Coordinated Motion and so would only work with our KMotionCNC (or other app using our TP) and not Mach3.  It uses a table which represents an xy grid of any size and number of rows and columns that you wish.  It assumes there is a theoretical perfect grid of points in CAD Space and the Geocorrection Table defines the actual actuator (motor) positions that would be required to position the tool exactly at each CAD position.  So for example one technique of creating the Table is to have something like a precision plate with 100 precision holes drilled into it (10 rows x 10 columns).  By Jogging the motors to position a tool exactly at each hole position you can push the "measure" button on the KMotionCNC Screen.  This will record to a disk file the xyz motor axis positions for each hole to build the required table.  The Coordinate Motion Kinematics will then use this table and bi-linear interpolate any CAD position between the measured points.  If just 4 points are used at the xy extremes then the bilinear interpolation can be made to just skew the entire space to correct for orthogonality (and scale, and trapezoidal errors).  Bi-linear interpolation is a Transformation.
 
Still confused by your term "lockstep" - but yes the two x motors would be homed simultaneously but independently and then slaved.  
 
Hope this helps.
 
Regards
TK
 

From: kai432 <kai@...>
To: DynoMotion@yahoogroups.com
Sent: Tuesday, June 5, 2012 4:40 AM
Subject: [DynoMotion] Re: Hello, and a question

 
Thanks Tom

I guess there are two things

1) Orthogonality - small offset could work - not entirely sure about deliberately putting the two X axis out of alignment though (increased dynamic errors and creepage over time)? Is it possible to have no brute force offset, but get the trajectory planner to re-project the vectors onto a corrected path? i.e. a line that was (0,0) to (0,Y) is now (0,0) to (Y sin theta,Y cos theta). Not sure if I got the maths right, I hope I painted the right picture...

Re: lockstep - I was thinking of slaved X's with independent homing but I'm happy enough with either implementation.

2) Non-linearity - If there are localised distortions, can the geometry table correct for those? E.g. one of the rails have a small bump, can the correction null out those errors? Or is it a matter of ensuring the physical rails are linear?

The general idea was understanding if the correction table puts the paths through some kind of a transformation.

Regards
Kai

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Kai,
>
> What do you mean by "running in lockstep"?
>
> Normally if you are using a slaved x axis you can adjust the xy orthogonality by performing a small move of one of the x motors after homing and before the two x motors are slaved together.
>
> Regards
> TK
>
>
>
> ________________________________
> From: Kai <kai@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, June 4, 2012 2:40 AM
> Subject: [DynoMotion] Hello, and a question
>
>
>
>  
> Hi all,
>
> New to the group (KFlop is in the mail!), so hi everyone.
>
> I'm using the MotionCNC/KFlop combo to support the CNC I'm building, and
> have some architectural type questions:
>
> How effective is the geometry correction table?
>
> Trying to figure out how I'm going to build in alignment adjustments at
> the physical level (making sure X Y Z are perpendicular, the two X axis
> rails are levelled, etc). How far can I count on the software
> correction to "do its thing"? Obviously if there are gross
> misalignments the machine will seize, but will the S/W handle
> corrections down to the resolution of the microsteps?
>
> To be clear, its a 3 axis machine and the long (X) axis will have a
> stepper on each side of the bed running in lockstep.
>
> I'm assuming that the correction table is a once and forget - the
> trajectory planner will automagically account for correction factors and
> future G codes don't even have to think about it.
>
> Thanks in advance for disabusing me of any delusions!
>
> Cheers
> Kai
>



Group: DynoMotion Message: 5148 From: kai432 Date: 6/5/2012
Subject: Re: Hello, and a question
Hi Tom,

Excuse me while I stop drooling. That's exactly what I was looking for, thanks. I will be using KMotionCNC.

Re: lockstep, that's just me plucking a word out of the dictionary - I just used it as a synonym for slaved. Wasn't trying to infer a greater level of synchronisation than that.

Cheers
Kai

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Kai,
>  
> Yes skewing slightly (or straightening) the axis is the way most handle Orthogonality.  Ideally the relaxed position should be nearly orthogonal.  It would be a good idea to have a switch detect excessive skew and kill power if skew ever becomes large in case of a motor failure or a mis-typed command which might cause only one motor to move.  Not sure how easy it would be to rig a switch to detect a small amount of skew, but I think it would be prudent if you can manage it.
>  
> Yes the Geo Correction table should be able to do either #1 or #2 of what you describe.  It only applies to our Trajectory Planner/Coordinated Motion and so would only work with our KMotionCNC (or other app using our TP) and not Mach3.  It uses a table which represents an xy grid of any size and number of rows and columns that you wish.  It assumes there is a theoretical perfect grid of points in CAD Space and the Geocorrection Table defines the actual actuator (motor) positions that would be required to position the tool exactly at each CAD position.  So for example one technique of creating the Table is to have something like a precision plate with 100 precision holes drilled into it (10 rows x 10 columns).  By Jogging the motors to position a tool exactly at each hole position you can push the "measure" button on the KMotionCNC Screen.  This will record to a disk file the xyz motor axis positions for each hole to build the required table. 
> The Coordinate Motion Kinematics will then use this table and bi-linear interpolate any CAD position between the measured points.  If just 4 points are used at the xy extremes then the bilinear interpolation can be made to just skew the entire space to correct for orthogonality (and scale, and trapezoidal errors).  Bi-linear interpolation is a Transformation.
>  
> Still confused by your term "lockstep" - but yes the two x motors would be homed simultaneously but independently and then slaved.  
>  
> Hope this helps.
>  
> Regards
> TK
>  
>
>
> ________________________________
> From: kai432 <kai@...>
> To: DynoMotion@yahoogroups.com
> Sent: Tuesday, June 5, 2012 4:40 AM
> Subject: [DynoMotion] Re: Hello, and a question
>
>
>  
>
> Thanks Tom
>
> I guess there are two things
>
> 1) Orthogonality - small offset could work - not entirely sure about deliberately putting the two X axis out of alignment though (increased dynamic errors and creepage over time)? Is it possible to have no brute force offset, but get the trajectory planner to re-project the vectors onto a corrected path? i.e. a line that was (0,0) to (0,Y) is now (0,0) to (Y sin theta,Y cos theta). Not sure if I got the maths right, I hope I painted the right picture...
>
> Re: lockstep - I was thinking of slaved X's with independent homing but I'm happy enough with either implementation.
>
> 2) Non-linearity - If there are localised distortions, can the geometry table correct for those? E.g. one of the rails have a small bump, can the correction null out those errors? Or is it a matter of ensuring the physical rails are linear?
>
> The general idea was understanding if the correction table puts the paths through some kind of a transformation.
>
> Regards
> Kai
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Kai,
> >
> > What do you mean by "running in lockstep"?
> >
> > Normally if you are using a slaved x axis you can adjust the xy orthogonality by performing a small move of one of the x motors after homing and before the two x motors are slaved together.
> >
> > Regards
> > TK
> >
> >
> >
> > ________________________________
> > From: Kai <kai@>
> > To: DynoMotion@yahoogroups.com
> > Sent: Monday, June 4, 2012 2:40 AM
> > Subject: [DynoMotion] Hello, and a question
> >
> >
> >
> >  
> > Hi all,
> >
> > New to the group (KFlop is in the mail!), so hi everyone.
> >
> > I'm using the MotionCNC/KFlop combo to support the CNC I'm building, and
> > have some architectural type questions:
> >
> > How effective is the geometry correction table?
> >
> > Trying to figure out how I'm going to build in alignment adjustments at
> > the physical level (making sure X Y Z are perpendicular, the two X axis
> > rails are levelled, etc). How far can I count on the software
> > correction to "do its thing"? Obviously if there are gross
> > misalignments the machine will seize, but will the S/W handle
> > corrections down to the resolution of the microsteps?
> >
> > To be clear, its a 3 axis machine and the long (X) axis will have a
> > stepper on each side of the bed running in lockstep.
> >
> > I'm assuming that the correction table is a once and forget - the
> > trajectory planner will automagically account for correction factors and
> > future G codes don't even have to think about it.
> >
> > Thanks in advance for disabusing me of any delusions!
> >
> > Cheers
> > Kai
> >
>